When developing airborne systems equipment software, it is common to practise a standard known as RTCA/DO-178B. The standard requires systems to be classified as to criticality level. The standard requires that a system that may cause or contribute to a malfunction of a certain degree of seriousness must be developed according to certain rules. Software is classified in 5 levels, A to E, where A corresponds the most critical one, and E the least critical level. Cost for developing A and B-class software is approximately three times the cost for developing D class software. There are no requirements in RTCA/DO-178B on E-class software, so it is hard to compare costs. Software must be developed according to class A if a software error may lead to a crash with casualties, to class B if the error may lead to extensive personal injuries or severely reduced safety levels, and further levels C, D, E corresponding to less severe effects of an error.
In many applications, erroneous information may lead to very serious consequences (in these applications, class A software would be applicable). As an example, consider a case where erroneous information is sent to a weapons system, leading to erroneous firing.
Software classified as type A or B is expensive to develop and is in principle not allowed to be integrated or executed on a commercial computer using commercial-off-the-shelf software (COTS software) such as Windows or Linux operating system. Traditionally, all systems within an information chain has therefore been developed to class A or B, for the kind of functions mentioned above.
In connection with the introduction of Unmanned Aerial Vehicles (UAVs) there is a need to safely control these vehicles using principally COTS-products. This is not an alternative if the traditional method, cf. above, is to be used to achieve a safe flow of information. Also in other applications, the traditional method results in higher economical costs than would be the case if products have a lower class of criticality than A or B, or what would be the case if COTS products could be used both for hardware and software.
A typical application for the invention is to make it possible to remotely control an UAV using (in part) low cost COTS computer and software products, still fulfilling the requirements of applicable safety standards such as RTCA/DO-178B.
An object of the present invention is to provide a method for communication in safety critical systems without having to use safety approved equipment in all the communication chain, while still being able to fulfil applicable safety standards, such as RTCA/DO-178B.
Another object is to provide a method for easily detecting communication errors without having to rely on safety approved equipment.
A communication method comprising of the following steps:                In a first entity, transferring a first set of data to a second set of data that represents the information in the first set of data as a number of graphical segments. These segments can be pixels (represented by x/y-coordinates), lines (represented by two sets of x/y-coordinates, defined the start and end-point of the line), polygons (defined by a number of x/y coordinates defined the corners of the polygons) or any other form of graphical segments.        Transmitting the second set of data via a third entity        Receiving the second set of data in a second entity        Displaying the graphical segments defined by the second set of data in the second entity.        Determining if the second data has been corrupted by the second or third entity.        Taken appropriate actions depending on the outcome of the above.        
Appropriate actions can be to either trust and use the information if it appears to not have been corrupted by the second or third entity or to take actions that will ensure that the first entity will know that information can no longer be received in a safe way. This can be accomplished by discontinuing a continuous communication between the first and second entity. This communication can be implemented using the following steps:                Continuously, from the first entity, sending a unique code.        Continuously, in the second entity, calculating a return value based on some algorithm.        Continuously, in the first entity, verifying that the calculated return value from the first entity is correct. If not so, the first entity is to take proper actions due to communications loss with the second entity.        